home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1998 May / EnigmA AMIGA RUN 27 (1998)(G.R. Edizioni)(IT)[!][issue 1998-05].iso / recent2 / poolme.readme < prev    next >
Text File  |  1998-04-19  |  19KB  |  472 lines
  1. Short:    Memory defragmentizer/AllocP superset
  2. Author:   thor@math.tu-berlin.de (Thomas Richter)
  3. Uploader: thor@math.tu-berlin.de (Thomas Richter)
  4. Version:  1.33
  5. Type:     util/sys
  6. Requires: OS 3.0
  7.  
  8. ______________________________________________________________________________
  9.  
  10.             Version History
  11. ______________________________________________________________________________
  12.  
  13. 1.33:
  14.  
  15. - Removed a bug in the PoolMem shutdown code. The pre-1.33 releases did not
  16.   free the scratch list completely.
  17. - Added the SCRATCHONLY keyword, it installs only the "scratchlist" of
  18.   PoolMem, not the dynamic pools.
  19. - Added the PUDDLESIZE, PUDDLETHRES and SHRINKTHRES keywords to make the 
  20.   parameters of the small memory pool adjustable.
  21. - Rewrote a lot of the kernal routines, mostly for optimizations.
  22. ______________________________________________________________________________
  23.  
  24. To "SaferPatches" users: 
  25.  
  26. To be able to remove PoolMem later on safely, PoolMem must be run AFTER 
  27. SaferPatches has been installed. Same goes of course for all other patches
  28. and the SaferPatches program.
  29. ______________________________________________________________________________
  30.  
  31. Photogenics: I got reports that this program crashes with PoolMem installed
  32. as soon as it is shut down. If anybody knows what's going on with this proggy,
  33. please let me know. It might be worth to check for correct memory allocation
  34. with MungWall and MemSniff.
  35. ______________________________________________________________________________
  36.  
  37. Developpers should check the "Developper.readme" file in this archive. It
  38. contains information about how to allocate and deallocate memory correctly.
  39. THESE AREN'T POOLMEM SPECIFIC INFORMATIONS! ALL OS FRIENDLY PROGRAMS HAVE
  40. TO OBEY THE RULES FORMULATED IN THIS FILE, they aren't my inventions.
  41. ______________________________________________________________________________
  42.  
  43. 1.32:
  44.  
  45. - Rewrote the startup segment completely. All 1.2 compatible code, argument
  46. parser etc... removed. 
  47. - Added a proper version check. PoolMem requires OS 3.0.
  48. - Added the NOMERGE option to avoid merging of FastMem of different speed.
  49. - As a result of the new argument parser, the CHIPFWD option DOES NO LONGER
  50.   include the "INSTALL" option, both arguments should be given.
  51. - The PoolMem algorithms hasn't been changed, though.
  52. - Included new versions of PatchRAM and ShowMem.
  53. - PoolMem 1.31 and above works fine on PowerUp-Systems. Thanks to Andreas
  54.   Kleinert for testing! However, the current version does not yet adjust
  55.   memory correctly for the PowerUp system, that's still left to the ppc.lib
  56.   and AllocP32. Might change in the future, though.
  57.  
  58. ______________________________________________________________________________
  59.  
  60. Compatibility node: The game demo "The Final Odyssey" crashes when PoolMem is
  61. active. Tracing this error down to its roots resulted in an aparent bug in
  62. the memory deallocation function of this game that occurs, too, with MungWall
  63. instead of PoolMem installed. Since EVERY CORRECT PROGRAM is supposed to run 
  64. with MungWall, I WON'T TRY to add a workaround for this bug. Just avoid buggy 
  65. programs, as usual. Thanks to Dirk Neubauer for the hint.
  66. ______________________________________________________________________________
  67.  
  68. 1.31:
  69.  
  70. PoolMem includes a patch for AllocAbs() to be able to allocate absolute memory
  71. from the scratch list. This *should* help to make PoolMem working with the
  72. 68040/68060/ppc library, thus, it should be possible to run PoolMem IN FRONT
  73. of these libraries, i.e. "SetPatch". Would be nice if somebody could sent me 
  74. a report whether this works now or not.
  75.  
  76. Additionally, new versions of the FragMeter and ShowMem program are included.
  77.  
  78. ______________________________________________________________________________
  79.  
  80. Several people reported instabilities when running PoolMem. I can't reproduce
  81. any of these crashes here at my system, thus if you find a REPRODUCABLE crash,
  82. please, please let me know! This version of PoolMem includes debug information
  83. that might help you and me to locate possible bugs. If possible, report bugs
  84. by giving the routine names directly.
  85.  
  86. It has been reported that PoolMem runs astonishingly slow on PowerUp boards.
  87. I've currently no explanation for this, if you've any idea about it, or know
  88. how to fix it - please report!
  89. ______________________________________________________________________________
  90.  
  91. 1.30:
  92.  
  93. This version introduces a major rewrite of all critical routines, especially
  94. the replacement AllocMem() and FreeMem() routine. This might mean that either
  95. old bugs have been fixed or new bugs have been introduced. Anyways, check out
  96. for possible bugs since this is a release with a "0" in the version.
  97. This version might be much faster than the 1.2x version, due to some 
  98. optimizations.
  99. WARNING: Since the new 1.30 release of PoolMem replaces the Exec memory
  100. functions completely, YOU MUST RUN POOLMEM IN FRONT OF OTHER MEMORY PATCHES.
  101. ESPECIALLY, RUN POOLMEM FIRST, MUNGWALL AFTERWARS or Mungwall will be non-
  102. functional.
  103.  
  104. _____________________________________________________________________________
  105.  
  106. 1.22:
  107.  
  108. PoolMem merges now automatically all adjacent memory lists of the same type.
  109.  
  110. ______________________________________________________________________________
  111.  
  112. NEWS FLASH: Found serious bug in XiPaint that caused crashes with PoolMem,
  113. check below for details.
  114. ______________________________________________________________________________
  115.  
  116. 1.21.1:
  117.  
  118. Included a new version of PatchRAM (check PatchRAM.readme for details),
  119. and a new version of the FragMeter program.
  120. _____________________________________________________________________________
  121.  
  122. 1.21:
  123.  
  124. PoolMem flushes now the memory as it should if called by AllocMem(-1,..).
  125. Except that, nothing changed.
  126. _____________________________________________________________________________
  127.  
  128. 1.20:
  129.  
  130. Added the CHIPFWD command. Works like INSTALL but allocates chip mem in
  131. standard (forwards) mode instead of backwards mode. Might solve strange
  132. compatibility problems. Added more sanity checks, included PatchReplyMsg
  133. to create warnings for broken programs.
  134. ______________________________________________________________________________
  135.  
  136. 1.19.1:
  137.  
  138. Changed the name of the DefragMeter to FragMeter because that makes more
  139. sense. Added a chunk count to this program. PoolMem itself unchanged.
  140. ______________________________________________________________________________
  141.  
  142. About PoolMem:
  143.     
  144.     If you run a lot of programs without resetting the system, you'll
  145. usually find that the main memory of the computer is getting "messed up",
  146. split in lots of tiny memory "snippets" that are more or less useless due to
  147. their tinyness. It may happen that you can't start an application even though
  148. enough memory is available - because this memory is too fragmentated to
  149. be of any use.
  150.  
  151. That's the point where PoolMem tries to help you: It manages the main memory
  152. in a way such that it can't get fragmentated too easely. It replaces also
  153. the function of AllocP, which is therefore obsolete.
  154.  
  155. ______________________________________________________________________________
  156.  
  157. Installation and Usage:
  158.  
  159.     Copy the PoolMem program in this archive to the C: directory of your
  160. system partition. Add the following line to your startup-sequence:
  161.  
  162. PoolMem INSTALL >NIL:
  163.  
  164.  
  165. You might also want to install "PatchRAM" which is included in this archive,
  166. too. It modifies the system RAM disk in a way that avoids memory 
  167. fragmentation, too. Another bonus is that the RAM disk will show its true
  168. size from now on, i.e. it won't be no longer 100% full.
  169.  
  170.  
  171. To remove PoolMem later on, open a shell window and enter
  172.  
  173. PoolMem remove
  174.  
  175.  
  176. The complete command template:
  177.  
  178. HELP/S,REMOVE/S,INSTALL/S,CHIPFWD/S,NOMERGE/S,
  179. SCRATCHONLY/S,PUDDLESIZE/N,SHRINKTRHES/N,PUDDLETHRES/N
  180.  
  181.  
  182. HELP:            Prints a small overview of the available options.
  183.  
  184. REMOVE:            Remove a previously installed version of PoolMem.
  185.  
  186. INSTALL:        Install the PoolMem patch.
  187.  
  188. CHIPFWD:        Don't allocate big chunks of chip memory in reverse
  189.             direction. 
  190.             NOTE: Starting with 1.32, this is no longer a
  191.             stand-alone option, INSTALL must be given, too.
  192.  
  193. NOMERGE:        Do not attempt to merge adjacent memory blocks of
  194.             the same type. Even if the memory types are equal,
  195.             the physical characteristics of the memory blocks
  196.             might differ (e.g. 32 bit memory vs. 16 bit memory).
  197.             Future versions of PoolMem might respect this.
  198.             fragmentation.
  199.  
  200. SCRATCHONLY:        Do to build memory pools for small block allocations,
  201.             but use the scratch list only.
  202.  
  203. PUDDLESIZE:        Set the "puddle size" for the small block memory pool.
  204.             If an allocation from the small memory pool fails, 
  205.             PoolMem attempts to enlarge the pool by this number
  206.             of bytes. Defaults to 8192.
  207.  
  208. PUDDLETHRES:        Set the "puddle threshold" for the small memory pool.
  209.             Allocations larger than this size are taken from the
  210.             large memory pool instead of the small memory pool.
  211.  
  212. SHRINKTHRES:        Set the "merge threshold". If more than PUDDLESIZE +
  213.             SHRINKTHRES bytes are unused at the end of the
  214.             small memory pool, the pool shrinks and the free
  215.             bytes enter the large pool. Defaults to 4096.
  216. ______________________________________________________________________________
  217.  
  218. Compatibility:
  219.  
  220.     There are a couple of relatively deep patches of the memory system
  221. that shouldn't be run together with PoolMem:
  222.  
  223. - SetPatch:    The 68040 library which is loaded by this program seems
  224.         to allocate the MMU tables in a strange way incompatible
  225.         to the scratch list of PoolMem. Easy solution: run
  226.         PoolMem after SetPatch.
  227.         This compatibility problems *should* have been fixed with
  228.         the 1.31 option, but hasn't been tested since I've a '030
  229.         on board.
  230. - MemSniff:    (The THOR MungWall replacement)    Patches deep into the memory
  231.         allocation routines, too deep for PoolMem.
  232.  
  233. I guess that's all for now...
  234.  
  235.  
  236. Buggy programs that crash with PoolMem installed:
  237.  
  238. - XiPaint 3.2 (or XMouse, to be precise):
  239.  
  240. The message handling of the mouse driver is broken. After a long debug 
  241. session deep into the night, I found that the crashes were created by the
  242. mouse driver XMouse. It replies messages that are no longer valid and have
  243. been FreeMem()'d before. THIS IS DEFINITELY ILLEGAL AND NOT A POOLMEM PROBLEM.
  244.  
  245. To help you checking other programs as well, I included a tiny patch
  246. "PatchReplyMsg". You shouldn't install it permanently, though, because it
  247. slows down the message system. If, after installation of this patch, a 
  248. program crashes with guru 0x01000001f, THEN THIS PROGRAM HAS THE SAME BUG
  249. AS XIPAINT and replies illegal messages. This will crash your system anyways,
  250. with or without PoolMem. Please sent a bug report to the author, or remove
  251. these programs. As I said, THIS IS NO POOLMEM problem.
  252.  
  253.  
  254. The guru 0x01000013 is rather typical for these programs - they invalidate
  255. the internal scratch list of PoolMem.
  256.  
  257.  
  258. - The Final Odyssey:
  259.  
  260. The memory deallocation routine of this program is buggy. It crashes, too,
  261. with MungWall installed. Since EVERY program that crashes with MungWall is
  262. NOT supposed to be system conformal, I WILL NOT add a workaround for this
  263. problem.
  264.  
  265. Additional node:
  266.  
  267. All PoolMem versions so far contain workarounds for:
  268.  
  269. o) Programs that rely on a "correctly" set zero-condition code of AllocMem()
  270.    ("PixMate")
  271.  
  272. o) the FFS/OFS ACTION_CLOSE bug that does not set the correct result code.
  273. This is currently done by the PoolMem FreeMem() replacement routine. However,
  274. the author of the FFS ("Heinz") has been informed, so it's likely that this
  275. error will be fixed in the next FFS release, probably for the FFS of the
  276. 3.5 workbench.
  277.  
  278. ______________________________________________________________________________
  279.  
  280. Theory of operation:
  281.  
  282.     PoolMem splits all available memory in two blocks: One block is used 
  283. for the small memory snippets (always taken from there), the other block is used
  284. for huge allocations. This partition of the main memory is dynamic, i.e. each
  285. sub-pool can grow and shrink, depending on the memory requirements.
  286.  
  287. The "public/ANY" memory gets a special treatment. PoolMem manages a "scratch"
  288. list for tiny memory blocks taken from there. Instead of taking these tiny
  289. memory blocks always from the main memory, they are taken from this (global,
  290. though) memory pool and put back into this pool if they get freed. A special
  291. garbage collection task cleans this "scratch list" from time to time, or if
  292. it overruns. The main profit is taken from the layers.library, which uses to
  293. allocate tons of tiny snippets and is therefore the main cause for memory
  294. fragmentation.
  295.  
  296. The "chip" memory is treated a bit different. It's also split into two 
  297. distinct memory pools (small and large), but memory from the large pool
  298. is allocated in reverse direction - unless you run PoolMem with the
  299. ChipFwd keyword, of course; this happens for two reasons: First, it
  300. helps to keep the memory defragmentated, so the big pool can't run that
  301. easely into the small pool. Second, it works around a hardware bug of my
  302. computer (the refresh of the high end chip memory in my computer seems to
  303. be a bit buggy - some bits tend to flip if they aren't frequently accessed,
  304. for example by the DMA processor as display memory.)
  305.  
  306. For details about the PatchRAM program, check its readme file. As I said, if
  307. you run PoolMem, you're supposed to run PatchRAM as well. It helps PoolMem
  308. a lot in its job! Future versions of PoolMem will include this patch as
  309. well, but the current version is not yet supposed to be "final" in any
  310. way.
  311.  
  312. _________________________________________________________________________________
  313.  
  314. Additional programs:
  315.  
  316. The PoolMem program is still in a somewhat experimental stage, even though
  317. it's running stable for my system for more than two years now - I won't
  318. expect any serious bugs, though.
  319. However, if you like to see how PoolMem works and if it has any effects, I
  320. provided several extra programs:
  321.  
  322. ShowMem:        Shows the allocated/free memory in a graphical over-
  323.             view. For details, check the ShowMem readme and its
  324.             guide. (Available separately as well)
  325.  
  326. PatchRAM:        Modifies and improves the RAM disk. Shows the correct
  327.             size of the RAM drive, improves the memory allocation
  328.             sheme of it as well. Should be run together with
  329.             PoolMem. For details, check the guide of PatchRAM.
  330.  
  331. FragMeter:        Calculates the fragmentation of your memory. The
  332.             output is given separately for each memory type.
  333.             A 100% fragmentation indicates that all the free
  334.             memory is messed up in tiny blocks of eight bytes
  335.             each (maximal fragmentation).
  336.             A Shannon-type approach is used to measure the
  337.             fragmentation (the algorithm calculates the Shannon
  338.             entropy of the memory blocks with the formula
  339.             sum += log(chunk->mc_Bytes/total)
  340.             If you know a better approach for measuring the
  341.             fragmentation, lemme now. This here seems at least
  342.             reasonable for me as a theoretical physicst... ;-)
  343.             
  344.             This program can be used to test the efficency of
  345.             PoolMem. My measurements indicate that the entropy is
  346.             about halved.
  347.  
  348. MemoryMess:        A program that tries to fragmentate the main memory
  349.             as bad as possible by allocating and freeing memory
  350.             in random order. Can be used together with the 
  351.             FragMeter to measure the efficiency of PoolMem or
  352.             with ShowMem to watch PoolMem at its job. Can be
  353.             canceled safely with ^C (Control-C). Does nothing
  354.             useful except that.
  355.  
  356. PatchReplyMsg:        Useful to find buggy programs, like XiPaint.
  357.             PatchReplyMsg will create a guru 0x0100001f if a
  358.             program attempts to reply an already de-allocated
  359.             message. Don't install it permanently, but use it
  360.             to find the reason for crashes.
  361.  
  362.  
  363. If you've ideas how to improve PoolMem, lemme know....
  364.  
  365. ______________________________________________________________________________
  366.  
  367. Guru meditations thrown by PoolMem:
  368.  
  369. 0x01000013        Scratch entry illegal.
  370.  
  371.             Some program invalidated the internal memory scratch
  372.             list of PoolMem - by overwriting memory that has been
  373.             deallocated before. An (in)famous example is XiPaint.
  374.             Run "PatchReplyMsg" and a debugger (e.g. COP) to check
  375.             for details.
  376.  
  377. 0x0100000f        MemHeader not found.
  378.  
  379.             Some program attempted to free a non-existing block
  380.             of memory. PoolMem (or exec) wasn't able to locate
  381.             the MemHeader.
  382.  
  383.  
  384. 0x01000011        MemHeader insane.
  385.  
  386.             PoolMem found a MemHeader whose number of available
  387.             bytes does not match the size of its pool.
  388.  
  389.  
  390. 0x01000012        Invalid DeleteHeader (internal).
  391.  
  392.             Someone tried to deallocate the "large" memory pool.
  393.             This is an internal guru, shouldn't happen. 
  394.  
  395. 0x01000014        Memory Pools unordered.
  396.  
  397.             Someone changed the order of the memory blocks, the
  398.             large memory block is no longer in front of the
  399.             small memory pool.
  400.  
  401.  
  402. Additionally, PoolMem throws all standard exec guru's - the 1.3x routines
  403. replace the OS functions completely. As a side effect, PoolMem MUST BE RUN
  404. IN FRONT OF OTHER MEMORY TOOLS, especially RUN POOLMEM FIRST, MUNGWALL LATER.
  405.  
  406. ______________________________________________________________________________
  407.  
  408.                         The THOR-Software Licence
  409.  
  410.  
  411. This License applies to the computer programs known as "PoolMem", "ShowMem",
  412. "FragMeter", "MemoryMess" and "ShowMem".
  413. The "Program", below, refers to such program.
  414.  
  415.  
  416. The programs and files in this distribution are freely distributable
  417. under the restrictions stated below, but are also Copyright (c)
  418. Thomas Richter.
  419.  
  420.  
  421. Distribution of the Program by a commercial organization without written
  422. permission from the author to any third party is prohibited if any payment
  423. is made in connection with such distribution, whether directly
  424. (as in payment for a copy of the Program) or indirectly (as in payment
  425. for some service related to the Program, or payment for some product
  426. or service that includes a copy of the Program "without charge";
  427. these are only examples, and not an exhaustive enumeration of prohibited
  428. activities). However, the following methods of distribution involving
  429. payment shall not in and of themselves be a violation of this restriction:
  430.  
  431.  
  432. (i) Posting the Program on a public access information storage and
  433. retrieval service for which a fee is received for retrieving information
  434. (such as an on-line service), provided that the fee is not
  435. content-dependent (i.e., the fee would be the same for retrieving the same
  436. volume of information consisting of random data).
  437.  
  438.  
  439.  
  440. (ii) Distributing the Program on a CD-ROM, provided that the files
  441. containing the Program are reproduced entirely and verbatim on such
  442. CD-ROM, and provided further that all information on such CD-ROM be
  443. redistributable for non-commercial purposes without charge.
  444.  
  445.  
  446.  
  447. Everything in this distribution must be kept together, in original
  448. and unmodified form.
  449.  
  450.  
  451.  
  452.  
  453. Limitations.
  454.  
  455. THE PROGRAM IS PROVIDED TO YOU "AS IS," WITHOUT WARRANTY. THERE IS NO
  456. WARRANTY FOR THE PROGRAM, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
  457. LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  458. PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE
  459. RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD
  460. THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
  461. SERVICING, REPAIR OR CORRECTION.
  462.  
  463.  
  464.  
  465. IF YOU DO NOT ACCEPT THIS LICENCE, YOU MUST DELETE ALL FILES CONTAINED IN
  466. THIS ARCHIVE.
  467.  
  468. ______________________________________________________________________________
  469.  
  470. Have fun,
  471.     Thomas        April 1998
  472.